home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0074.001 < prev    next >
Text File  |  1993-07-28  |  16KB  |  476 lines
  1.  
  2.  
  3.   | Document: FSC-0074
  4.   | Version:  001
  5.   | Date:     28th July 1993
  6.   | Author:   John Souvestre, David Troendle, Bob Davis, George Peace
  7.   |
  8.   | FTS-0004.002 -- proposed
  9.  
  10.  
  11.                       EchoMail Specification
  12.  
  13.                             June, 1992
  14.  
  15.                       This document began as
  16.               the Conference Mail System User Manual
  17.                 By Bob Hartman t/a Spark Software
  18.           FidoNet(tm) node 132/101 (currently 1:104/501)
  19.                        Used with permission
  20.  
  21.   Revision 2:
  22.  
  23.        06 Jun 1991
  24.        John Souvestre, David Troendle, Bob Davis
  25.  
  26.        29 Oct 1991
  27.        John Souvestre, David Troendle
  28.  
  29.        28 Jan 1992
  30.        George Peace
  31.  
  32.        02 Jun 1992
  33.        George Peace
  34.  
  35.  
  36.  
  37.                          ECHOMAIL DEFINED
  38.  
  39.   EchoMail is a technique that permits several nodes on a
  40.   network to share a message base. It is similar in concept to
  41.   the conferences available on commercial information services
  42.   but is most closely related to the Usenet system consisting of
  43.   thousands of systems world wide.  All systems sharing a given
  44.   conference see any messages entered into the conference by any
  45.   of the participating systems.  This can be implemented in such
  46.   a way as to be totally transparent to the users of a
  47.   particular system.  In fact, they may not even be aware of the
  48.   network being used to move their messages about from node to
  49.   node!
  50.  
  51.   Unfortunately, EchoMail has disadvantages as well.  Many users
  52.   who are not educated about EchoMail systems do not realize the
  53.   messages transmitted cost MANY sysops (system operators)
  54.   money, not just the local sysop.  This is an important
  55.   consideration in EchoMail and should not be taken lightly.  In
  56.   a conference with 100 systems participating the cost per
  57.   message can be quite high.
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.                     BRIEF HISTORY OF ECHOMAIL
  65.  
  66.   In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
  67.   convenient means of sharing ideas with the other Dallas
  68.   sysops.  He created a system of programs he called Echomail,
  69.   and the Dallas sysops' Conference was born.
  70.  
  71.   Within a short time sysops in other areas began hearing of
  72.   this marvelous new gadget and EchoMail took on a life of its
  73.   own.  Today the FidoNet public network boasts a myriad of
  74.   conferences varying in size from a handful of participants to
  75.   Sysop conferences with hundreds of participants.  It is not
  76.   uncommon for a system to carry hundreds or more conferences
  77.   and share those conferences with 10 or more nodes.
  78.  
  79.  
  80.  
  81.                         HOW ECHOMAIL WORKS
  82.  
  83.   Today's EchoMail processing is functionally compatible with
  84.   the original EchoMail utilities.  In general, the process is:
  85.  
  86.     -  A message is entered into a designated area on a FidoNet
  87.        compatible system.
  88.  
  89.     -  This message is "Exported" along with some 'control
  90.        information' to each system "linked" to the conference
  91.        through the originating system.
  92.  
  93.     -  Each receiving system "Imports" the message into the
  94.        proper Conference Mail area.
  95.  
  96.     -  The receiving systems then "Export" these messages, along
  97.        with additional control information, to each of their own
  98.        EchoMail links.
  99.  
  100.     -  Return to the import step.
  101.  
  102.   The method is quite simple in general.  Of course, following
  103.   the steps literally means messages would never stop being
  104.   Exported and transmitted to other systems.  This obviously
  105.   would not be desired.  The information contained in the
  106.   'control information' section is used to prevent exporting the
  107.   same message more than once to a single system.
  108.  
  109.  
  110.  
  111.                    MESSAGE CONTROL INFORMATION
  112.  
  113.   Control information is associated with each EchoMail message.
  114.   This information consists of certain special lines placed
  115.   inside the message.  These lines are typically inserted
  116.   automatically by the program which prepares or processes the
  117.   message, not by the person writing it.
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.   In FTS-0001 terminology, these control information lines shall
  125.   be inside the "text" field of a "packed message".
  126.  
  127.   Control information lines shall contain only ASCII characters,
  128.   from 32 to 126, except the first character of the path line
  129.   and as noted elsewhere in this document.  This limitation
  130.   applies only to control information lines.
  131.  
  132.   Alphabetic characters in required literal strings (AREA,
  133.   Origin, SEEN-BY, and PATH) are case-sensitive.
  134.  
  135.   All control information lines shall be terminated with ASCII
  136.   character 13 (carriage return).
  137.  
  138.   These required control information lines determine how
  139.   EchoMail is handled:
  140.  
  141.  
  142.  
  143.   1. Area line
  144.  
  145.   There shall be exactly one area line in an exported message.
  146.   The AREA line:
  147.  
  148.     -  Shall be the first line of the text and thus shall
  149.        immediately follow the packed message header.  This
  150.        position is "offset 0" of the "text" portion of the
  151.        packed message.
  152.  
  153.     -  Shall be formatted as:
  154.  
  155.             AREA:CONFERENCE
  156.  
  157.             AREA: is a required five character upper case
  158.             literal.
  159.  
  160.             CONFERENCE is the name of the conference. The
  161.             conference name is composed of ASCII characters in
  162.             the range 33 to 96 and 123 to 126.  The conference
  163.             name shall be no more than 60 characters in length.
  164.  
  165.   The AREA line is added when a conference is "Exported" to
  166.   other systems.  It is based upon information found in a
  167.   configuration file for the designated message area.  This
  168.   field is used by receiving systems to "Import" messages into
  169.   the correct EchoMail area.
  170.  
  171.   Some implementations insert a Ctrl-A (0x01) immediately
  172.   preceding the AREA: literal (^AAREA:CONFERENCE).
  173.  
  174.   Six months after adoption of this document the ^AAREA: format
  175.   shall be processed equally with the AREA: format when either
  176.   occurs in received packets.
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.   2. Origin Line
  186.  
  187.   There shall be exactly one origin line in a message.  It shall
  188.   be placed in the message following all user entered
  189.   information and immediately before the remaining control
  190.   information lines.
  191.  
  192.   The origin line:
  193.  
  194.     -  Shall begin with the eleven character literal:
  195.  
  196.             <space>*<space>Origin:<space>
  197.  
  198.     -  Is optionally followed by user/system defined data in the
  199.        ASCII range 32 to 126.
  200.  
  201.     -  Shall end with a FidoNet network address enclosed in
  202.        parenthesis:
  203.  
  204.             ([<zone>:]<net>/<node>[.<point>][@<domain>])
  205.  
  206.     -  Shall be no more than 79 characters long including the
  207.        required lead-in and address information.
  208.  
  209.     -  Shall be inserted into the message at the originating
  210.        system.
  211.  
  212.   The complete line might look like:
  213.  
  214.             * Origin: Conference Mail BBS (1:132/101)
  215.  
  216.  
  217.  
  218.   3. Seen-by Lines
  219.  
  220.   Seen-by lines are the focus of EchoMail distribution control
  221.   information.  They are used to determine which addresses
  222.   (systems) have received messages.  There can be as many seen-
  223.   by lines as required to store the necessary information.
  224.  
  225.   Seen-by lines consist of "SEEN-BY:<space>", followed by a list
  226.   of net/node numbers corresponding to the systems which have
  227.   received that message.  The net/node number of each system to
  228.   which a message is exported is added to the seen-by lines at
  229.   the time of export.
  230.  
  231.   There shall be exactly one set of seen-by lines in a message.
  232.   Seen-by lines:
  233.  
  234.     -  Shall follow the origin line.
  235.  
  236.     -  Shall begin with the nine character literal:
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.             SEEN-BY:<space>
  244.  
  245.     -  Shall contain a list of net/node numbers.
  246.  
  247.     -  Shall be no more than 80 characters long including the
  248.        required literal.
  249.  
  250.   The complete lines might look like:
  251.  
  252.             SEEN-BY: 104/1 501 132/101 113 136/601 1014/1
  253.             SEEN-BY: 1014/2 3
  254.  
  255.   The list of net/node numbers:
  256.  
  257.     -  Shall identify at least one address. "Blank" seen-by
  258.        lines shall not be transmitted.
  259.  
  260.     -  Shall be sorted in ascending net/node order.
  261.  
  262.     -  Shall not contain repeated node numbers.
  263.  
  264.     -  Shall use only "2D" net/node notation.
  265.  
  266.     -  May use short form address notation where a net number is
  267.        listed once on any one line.  These 2 lines are
  268.        equivalent:
  269.  
  270.             SEEN-BY: 104/1 104/501 132/101 132/113 136/601
  271.             SEEN-BY: 104/1 501 132/101 113 136/601
  272.  
  273.   Some implementations insert a Ctrl-A (0x01) immediately
  274.   preceding the SEEN-BY: literal (^ASEEN-BY:).
  275.  
  276.   Six months after adoption of this document the ^ASEEN-BY:
  277.   format shall be processed equally with the SEEN-BY: format
  278.   when either occurs in received packets.
  279.  
  280.  
  281.  
  282.   4. Path Lines
  283.  
  284.   Path lines identify a list of net/node numbers that processed
  285.   a message before it reached the current system.  There can be
  286.   as many path lines as required to store the necessary
  287.   information.
  288.  
  289.   This is different from seen-by lines, in that seen-by lines
  290.   list list all systems to which the message has been sent while
  291.   path lines list the systems which have processed the message.
  292.  
  293.   There shall be exactly one set of path lines in a message.
  294.   Path lines:
  295.  
  296.     -  Shall follow seen-by lines.
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.     -  Shall be the last line(s) in the text field of a packed
  304.        message.
  305.  
  306.     -  Shall begin with the seven character literal:
  307.  
  308.             ^APATH:<space>
  309.  
  310.        The ^A is a special character which stands for Control-A
  311.        (ASCII character 1), and is required at the beginning of
  312.        each path line.
  313.  
  314.     -  Shall contain a list of net/node numbers.
  315.  
  316.     -  Shall be no more than 80 characters long including the
  317.        required literal.
  318.  
  319.   The complete path line might look like:
  320.  
  321.             ^APATH: 132/101 1014/1
  322.  
  323.   The list of net/node numbers:
  324.  
  325.     -  Shall identify at least one net/node number.  "Blank"
  326.        path lines shall not be transmitted.
  327.  
  328.     -  Shall not be sorted.  They shall remain in the order
  329.        representing the actual "path" along which the message
  330.        traveled.
  331.  
  332.     -  Shall use only "2D" net/node notation.
  333.  
  334.     -  Shall begin with the net/node of the originating system.
  335.  
  336.     -  Shall not be deleted during processing.  The original
  337.        path information shall be maintained from origin to final
  338.        destination.
  339.  
  340.  
  341.  
  342.                         ECHOMAIL TOPOLOGY
  343.  
  344.   The way in which systems link together for a particular
  345.   conference is called the "EchoMail Topology."  It is important
  346.   to know this structure for two reasons:
  347.  
  348.     -  It is important to have a topology which is efficient in
  349.        the transfer of the EchoMail messages.
  350.  
  351.     -  It is important to have a topology which will not cause
  352.        systems to see the same messages more than once.
  353.  
  354.   Efficiency can be measured in a number of ways:
  355.  
  356.     -  Least time involved for all systems to receive a message
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.     -  Least cost for all systems to receive a message
  364.  
  365.     -  Fewest phone calls required for all systems to receive a
  366.        message.
  367.  
  368.   Users of EchoMail systems have determined (through trial and
  369.   error) the best measure of efficiency to be a combination of
  370.   all three measurements.  Balancing the equation is not
  371.   trivial, but some guidelines can be offered:
  372.  
  373.     -  Have nodes form "stars" for distribution of EchoMail.
  374.        This arrangement has several nodes all receiving their
  375.        EchoMail from the same system.  In general the systems on
  376.        the "outside" of the star poll the system on the
  377.        "inside".  The system on the "inside" in turn polls other
  378.        systems in a similar star configuration to receive the
  379.        EchoMail that is being passed on to the "outside"
  380.        systems.
  381.  
  382.     -  Utilize fully connected polygons with few vertices.
  383.        Nodes can be connected in a triangle (A sends to B and C,
  384.        B sends to A and C, C sends to A and B) or a fully
  385.        connected square (all corners of the square send to all
  386.        of the other corners).  This method is useful for getting
  387.        EchoMail messages to each node as quickly as possible.
  388.  
  389.   All of these efficiency guidelines have to be tempered with
  390.   the guidelines dealing with keeping duplicate messages from
  391.   being exported.  Duplicates will occur in any topology that
  392.   forms a closed polygon that is not fully connected.  Take for
  393.   example the following configuration:
  394.  
  395.             A ----- B
  396.             |       |
  397.             |       |
  398.             C ----- D
  399.  
  400.   This square is a closed polygon that is not fully connected.
  401.   It is capable of generating duplicates:
  402.  
  403.     1. A message is entered on node A.
  404.  
  405.     2. Node A exports the message to node B and node C placing
  406.        the seen-by for A, B, and C in the message as it does so.
  407.  
  408.     3. Node B sees that node D is not listed in the seen-by and
  409.        exports the message to node D.
  410.  
  411.     4. Node C sees that node D is not listed in the seen-by and
  412.        exports the message to node D.
  413.  
  414.   At this point node D has received the same message twice - a
  415.   duplicate was generated.
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.   Normally a "dup-ring" will not be as simple as a square.
  423.   Generally it will be caused by a system on one end of a long
  424.   chain accidentally connecting to a system on the other end of
  425.   the chain.  This causes the two ends of the chain to become
  426.   connected, forming a polygon.
  427.  
  428.   In FidoNet this problem is reduced somewhat by having a
  429.   regional EchoMail star distribution architecture that
  430.   maintains EchoMail connections within regions of the world.
  431.   Within that architecture only a small number of prearranged
  432.   systems (regional collection systems) make inter-regional
  433.   connections.  This architecture, along with multiple daily
  434.   connections, results in an efficient topology which typically
  435.   allows global distribution within 24 hours.
  436.  
  437.  
  438.  
  439.                     THE PATH LINE AND TOPOLOGY
  440.  
  441.   The PATH line stores the net/node numbers of each system
  442.   having actually processed a message.  This information is
  443.   useful in correcting the biggest problem encountered by nodes
  444.   running an Echomail compatible system - the problem of finding
  445.   the cause of duplicate messages.  How does the PATH line help
  446.   solve this problem?  Take the following path line as an
  447.   example:
  448.  
  449.             ^APATH: 107/6 107/312 132/101
  450.  
  451.   This shows that the message was processed by system 107/6 and
  452.   transferred to system 107/312.  It further shows system
  453.   107/312 transferred the message to 132/101, and 132/101
  454.   processed it again.  Here's another example:
  455.  
  456.             ^APATH: 107/6 107/312 107/528 107/312 132/101
  457.  
  458.   This shows the message having been processed by node 107/312
  459.   on more than one occasion.  Based upon the earlier description
  460.   of the 'information control' fields in Echomail messages, this
  461.   identifies an error in processing.  This further shows node
  462.   107/528 as the node which apparently processed the message
  463.   incorrectly.  In this case the path line can be used to help
  464.   locate the source of duplicate messages or topology problems.
  465.  
  466.   In a conference with many participants it becomes almost
  467.   impossible to determine the exact topology used.  In these
  468.   cases the use of the path line can help a moderator or
  469.   distributor of a conference track any possible breakdowns in
  470.   the overall topology, while not substantially increasing the
  471.   amount of information transmitted.  Having this small amount
  472.   of information added to each message pays for itself very
  473.   quickly when it can be used to help detect a topology problem
  474.   causing duplicate messages to be transmitted to each system.
  475.  
  476.